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Why They Don’t “Need” 
Requirements 

It’s more fun to design and build the 
system 

This is the next system in a series, we just 
need to make a few tweaks 

It’s an “in-house” build, we’ll just tell the 
designers what we need 

We don’t have time 

We don’t need them, they’ll hinder 
innovation 



What the Project Does 

Copy requirements from past systems 

Develop requirements without proper 
systems engineering 

Develop requirements in parallel with trade 
studies and Concept of Operations 

Proceed to design without requirements 



What Happens 

Systems that meet requirements but fall 
short of meeting customer expectations 

Systems that are difficult to verify 

Systems with interface issues 

Projects cancelled due to failure to stay 
within budget and schedule limitations 



Pay Me Now or 
Pay Me More Later 
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Lesson 



APOIXO EXPERIENCE REPORT - 
GUIDANCE AND CONTROL SYSTEMS 

Raymond E. Wilson, Jr. 

Lyndon B. Johnson Space Center 
Houston, Texas 77058 



NA1I0NAE AERONAUTICS AND SPACE ADMINISTRATION • WASHINGTON, 0. C. * JUNE 1976 


d- Apollo 1976 


CONCLUDING REMARKS AND RECOMMENDATIONS 


During th* course ctf the development, qualification, and flight programs h the 
Apollo guidance and control systems performed bn ait Uutat*ndtlii*[ manner. There were 
no guidance and control failure e or malfunctions that precluded mission completion or 
that plated the flight trew or the mission in jeopardy. 

In general* the approaches that were used to establish and impitment guidance and 
Control system Interfaces and checkout procedures during the Integration el the systems 
bn the spacecraft appear to have been sound, Consequently, few interface problems 
appeared during the Integration of the systems into tint spacecraft, Some Of the more 
significant items that deserve careful consideration on future programs are as- follows. 

1. A strong effort should be made to estaPlisli baseline requirements tefore th# 
start of hardware design and software development processes- Per example, change S 
Affecting hand controllers, humidity, and In -flight maintenance caused major redesign 
effort#. 


2, A failure-analysis technl be developed to assist In the Identification 

Of Single -point failures. The Apollf^^^^^Hn which many engineers must search 
diagrams for problems, it nut iili-ug ;ssful fur complex systems. 



A strong effort should be made to 
establish baseline requirements before 
the start of hardware design and software 
development processes. For example, 
changes affecting hand controllers, 
humidity, and in-flight maintenance 
caused major redesign efforts. 
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Why Requirements? 

Ensure that you deliver the right system 
that meets your customer’s vision 

Avoid scope creep and gold plating 

Bound your system to fit your cost and 
schedule constraints 

Minimize change traffic that results in 
increased costs and delays in the 
schedule 



How do you get there? 

Define the vision of your system 

Develop a Concept of Operations to 
capture the system vision 

Secure stakeholder agreement on the 
vision 

Develop requirements documenting 
characteristics, features and functions that 
your system must have in order to meet 
the Concept of Operations 

Validate the Requirements i 



Define the Vision 


• What is the need for the system? 

• What is it going to do? 

• What are the constraints? 

• Who are the stakeholders? 
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Develop the Concept of 


Operations 

Operational Scenarios 
Interfaces 

Candidate Architectures 



Prototypes 
Trade Studies 


raw 





Secure Stakeholder Agreement 
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Develop Requirements 

• Characteristics, features and functions that 
your system needs to meet the vision 

• Attainable 

• Necessary 

• Verifiable 

• Unambiguous 
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Validate the Requirements 


• Ensure that the requirements correct and 
complete 

• Characteristics, features and functions required to 
meet the system vision 

• Interfaces 


Proper traceability to parent requirements 
Attainable, verifiable and necessary 
Unambiguous 
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Final Thoughts 

Requirements Development is key to 
ensuring 

• The system will meet your customer’s needs 

• The system will be delivered within the cost 
limit 

• The system will be delivered on time 

It’s not Rocket Science if you follow 
Systems Engineering Best Practices 
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